feat: Management Access utilities by labrenbe · Pull Request #1290 · stackabletech/operator-rs

labrenbe · 2026-10-01T12:08:29Z

Description

Adds shared utilities required for stackabletech/kafka-operator#1028.

labels and selectors for agents
new enum for platform access with TLS

Depends on https://github.com/stackabletech/decisions/issues/98 and https://github.com/stackabletech/decisions/issues/99.

Definition of Done Checklist

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
Please make sure all these things are done and tick the boxes

Author

Changes are OpenShift compatible
CRD changes approved
CRD documentation for all fields, following the style guide.
Integration tests passed (for non trivial changes)
Changes need to be "offline" compatible

Reviewer

Code contains useful comments
Code contains useful logging statements
(Integration-)Test cases added
Documentation added or updated. Follows the style guide.
Changelog updated
Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Feature Tracker has been updated
Proper release label has been added

…servedGeneration

xeniape · 2026-10-26T08:26:57Z

+        Retain,
+
+        /// Delete the resource in the product.
+        Delete,


Question regarding a specific scenario: I guess it would be possible for someone to create a KafkaTopic object with a Kafka topic they theoretically shouldn't have permissions for and then just delete that object, in turn deleting that Kafka topic in the cluster. Would that be covered with authorization somehow? That scenario would be relevant for different user groups managing different topics in the same cluster but I think Kafka has also some system topics?

In general I believe this is always a security risk with declarative resources in products.

For me the most important defense is definitely k8s RBAC on the KafkaCluster CRD preventing unauthorized users from taking creating KafkaTopics with arbitrary names. Also the principle used by the agent inside Kafka should have limitations on what it can and can't do.

Specifically for Kafka I'm also considering adding a validation on the topic name rejecting the prefix __ which is used by some internal topics.

If we have a topic per cluster, we could store the topic ID in the cluster resource? Only if these match (or is set) we know it is managed by us?

For the internal topics: We explicitly offer naming the topic different from the custom resource name. Why is that? E.g. with Trino catalogs, the name is the one of the resource (with options to tweak).
https://docs.stackable.tech/home/stable/trino/usage-guide/catalogs/#_catalog_name_tweaking

xeniape · 2026-10-26T09:06:48Z

Claude noted down some possible lifecycle problems/decisions:

The managed object would need a finalizer on deletion, otherwise the object gets deleted right away and the agent might not have had enough time reading the specs of the object needed to execute deletion logic in the product. So the object might never get deleted. So the finalizer would be definitely needed.
BUT with the finalizer another problem pops up: the deletion process might get stuck if there is no one removing that finalizer again. This can happen in different scenarios, for example someone could delete the product cluster or namespace and if the agent gets removed because of that before the deletion process is done and the finalizer removed, there is no one to remove that finalizer so the namespace deletion is stuck. So either the agent needs to stay alive until everything is processed or someone else (operator?) needs to release the objects

Not sure if this is part of this PR or not, but it seemed general enough to mention it in the operator-rs changes, if this provides some mechanism for all the operators.

…e conditions

labrenbe · 2026-10-26T19:55:21Z

Claude noted down some possible lifecycle problems/decisions:

* The managed object would need a finalizer on deletion, otherwise the object gets deleted right away and the agent might not have had enough time reading the specs of the object needed to execute deletion logic in the product. So the object might never get deleted. So the finalizer would be definitely needed.

* BUT with the finalizer another problem pops up: the deletion process might get stuck if there is no one removing that finalizer again. This can happen in different scenarios, for example someone could delete the product cluster or namespace and if the agent gets removed because of that before the deletion process is done and the finalizer removed, there is no one to remove that finalizer so the namespace deletion is stuck. So either the agent needs to stay alive until everything is processed or someone else (operator?) needs to release the objects

Not sure if this is part of this PR or not, but it seemed general enough to mention it in the operator-rs changes, if this provides some mechanism for all the operators.

Yes, the idea is to have the operator clean up after a KafkaCluster (or the whole Namespace) has been deleted and there is no agent left to clean up finalizers. As the cluster is being deleted anyway the operator only has to remove finalizers and doesn't need to take action in Kafka.

For me this logic is a candidate to extract into operator-rs in the future.

maltesander · 2026-10-27T06:53:41Z

+        Retain,
+
+        /// Delete the resource in the product.
+        Delete,


If we have a topic per cluster, we could store the topic ID in the cluster resource? Only if these match (or is set) we know it is managed by us?

For the internal topics: We explicitly offer naming the topic different from the custom resource name. Why is that? E.g. with Trino catalogs, the name is the one of the resource (with options to tweak).
https://docs.stackable.tech/home/stable/trino/usage-guide/catalogs/#_catalog_name_tweaking

labrenbe added 2 commits October 1, 2026 13:58

add agent label utility

e8a291d

add TlsClientCredential enum as platform access utility

6ca45a0

labrenbe self-assigned this Oct 1, 2026

labrenbe force-pushed the feat/platform-access branch from c3e3121 to 3be4832 Compare October 1, 2026 12:09

add changelog entry

7cb677e

labrenbe force-pushed the feat/platform-access branch from 3be4832 to 7cb677e Compare October 1, 2026 12:12

labrenbe added 2 commits October 1, 2026 14:12

fix cargo deny by upgrading yoke-derive

7a0d956

use hard-coded volume and mount names

f3d2da7

labrenbe mentioned this pull request Oct 2, 2026

feat: Kafka agent stackabletech/kafka-operator#1028

Open

6 of 20 tasks

labrenbe added 4 commits October 6, 2026 14:37

add support for anonymous platform access

3b91d73

make crd fragments versioned

e364acd

add ManagementPolicy CRD fragment

7687938

add Ready & Synced conditions for resources reconciled by agents

754e444

maltesander reviewed Oct 13, 2026

View reviewed changes

Comment thread crates/stackable-agent/src/condition.rs

rename tls client cert dir

92e1a36

adwk67 reviewed Oct 21, 2026

View reviewed changes

Comment thread crates/stackable-operator/src/crd/platform_access/tls/v1alpha1_impl.rs Outdated

adwk67 reviewed Oct 21, 2026

View reviewed changes

Comment thread crates/stackable-operator/src/v2/kvp/label.rs Outdated